home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pppext-frame-relay-02.txt < prev    next >
Text File  |  1993-10-07  |  15KB  |  608 lines
  1.  
  2.  
  3.  
  4. Network Working Group                                        W A Simpson
  5. Internet Draft                                                Daydreamer
  6. expires in six months                                       October 1993
  7.  
  8.  
  9.                            PPP in Frame Relay
  10.                   draft-ietf-pppext-frame-relay-02.txt
  11.  
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.    This document is the product of the Point-to-Point Protocol Working
  17.    Group of the Internet Engineering Task Force (IETF).  Comments should
  18.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  19.  
  20.    Distribution of this memo is unlimited.
  21.  
  22.    This document is an Internet Draft.  Internet Drafts are working
  23.    documents of the Internet Engineering Task Force (IETF), its Areas,
  24.    and its Working Groups.  Note that other groups may also distribute
  25.    working documents as Internet Drafts.
  26.  
  27.    Internet Drafts are draft documents valid for a maximum of six
  28.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  29.    other documents at any time.  It is not appropriate to use Internet
  30.    Drafts as reference material or to cite them other than as a
  31.    ``working draft'' or ``work in progress.''
  32.  
  33.    Please check the 1id-abstracts.txt listing contained in the
  34.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  35.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  36.    current status of any Internet Draft.
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. Simpson                  expires in six months                  [Page i]
  56. DRAFT                      PPP in Frame Relay               October 1993
  57.  
  58.  
  59. Abstract
  60.  
  61.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  62.    transporting multi-protocol datagrams over point-to-point links.
  63.  
  64.    This document describes the use of Frame Relay for framing PPP
  65.    encapsulated packets.
  66.  
  67.  
  68. Applicability
  69.  
  70.    This specification is intended for those implementations which desire
  71.    to use facilities which are defined for PPP, such as the Link Control
  72.    Protocol, Network-layer Control Protocols, authentication, and
  73.    compression.  These capabilities require a point-to-point
  74.    relationship between peers, and are not designed for multi-point or
  75.    multi-access environments.
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110. Simpson                  expires in six months                 [Page ii]
  111. DRAFT                      PPP in Frame Relay               October 1993
  112.  
  113.  
  114. 1.  Introduction
  115.  
  116.  
  117.    Frame Relay [2] is a relative newcomer to the serial link community.
  118.    Like X.25, the protocol was designed to provide virtual circuits for
  119.    connections between stations attached to the same Frame Relay
  120.    network.  The improvement over X.25 is that Q.922 is restricted to
  121.    delivery of packets, and dispenses with sequencing and flow control,
  122.    simplifying the service immensely.
  123.  
  124.    PPP uses ISO 3309 HDLC as a basis for its framing [3].
  125.  
  126.    When Frame Relay is configured as a point-to-point circuit, PPP can
  127.    use Frame Relay as a framing mechanism, ignoring its other features.
  128.    This is equivalent to the technique used to carry SNAP headers over
  129.    Frame Relay [4].
  130.  
  131.    At one time, it had been hoped that PPP HDLC frames and Frame Relay
  132.    would co-exist on the same links.  Unfortunately, the Q.922 method
  133.    for expanding the address from 1 to 2 to 4 octets is not
  134.    indistinguishable from the ISO 3309 method, due to the structure of
  135.    its Data Link Connection Identifier (DLCI) subfields.
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165. Simpson                  expires in six months                  [Page 1]
  166. DRAFT                      PPP in Frame Relay               October 1993
  167.  
  168.  
  169. 2.  Physical Layer Requirements
  170.  
  171.    PPP treats Frame Relay framing as a bit synchronous link.  The link
  172.    MUST be full-duplex, but MAY be either dedicated (permanent) or
  173.    switched.
  174.  
  175.    Interface Format
  176.  
  177.       PPP presents an octet interface to the physical layer.  There is
  178.       no provision for sub-octets to be supplied or accepted.
  179.  
  180.    Transmission Rate
  181.  
  182.       PPP does not impose any restrictions regarding transmission rate,
  183.       other than that of the particular Frame Relay interface.
  184.  
  185.    Control Signals
  186.  
  187.       Implementation of Frame Relay requires the provision of control
  188.       signals, which indicate when the link has become connected or
  189.       disconnected.  These in turn provide the Up and Down events to the
  190.       LCP state machine.
  191.  
  192.       Because PPP does not normally require the use of control signals,
  193.       the failure of such signals MUST NOT affect correct operation of
  194.       PPP.  Implications are discussed in [2].
  195.  
  196.    Encoding
  197.  
  198.       The definition of various encodings is the responsibility of the
  199.       DTE/DCE equipment in use, and is outside the scope of this
  200.       specification.
  201.  
  202.       While PPP will operate without regard to the underlying
  203.       representation of the bit stream, Frame Relay requires NRZ
  204.       encoding.
  205.  
  206.  
  207. 3.  The Data Link Layer
  208.  
  209.    This specification uses the principles, terminology, and frame
  210.    structure described in "Multiprotocol Interconnect over Frame Relay"
  211.    [4].
  212.  
  213.    The purpose of this specification is not to document what is already
  214.    standardized in [4].  Instead, this document attempts to give a
  215.    concise summary and point out specific options and features used by
  216.    PPP.
  217.  
  218.  
  219.  
  220. Simpson                  expires in six months                  [Page 2]
  221. DRAFT                      PPP in Frame Relay               October 1993
  222.  
  223.  
  224. 3.1.  Frame Format
  225.  
  226.    As described in [4], Q.922 header address and control fields are
  227.    combined with the Network Layer Protocol Identifier (NLPID), which
  228.    identifies the encapsulation which follows.  The fields are
  229.    transmitted from left to right.
  230.  
  231.     0                   1                   2                   3
  232.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  233.    +-+-+-+-+-+-+-+-+
  234.    |  Flag (0x7e)  |
  235.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  236.    |         Q.922 Address         |    Control    |  NLPID(0xcf)  |
  237.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  238.    |         PPP Protocol          |
  239.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  240.  
  241.    The PPP Protocol field and the following Information and Padding
  242.    fields are described in the Point-to-Point Protocol Encapsulation
  243.    [1].
  244.  
  245.  
  246. 3.2.  Modification of the Basic Frame
  247.  
  248.    The Link Control Protocol can negotiate modifications to the basic
  249.    frame structure.  However, modified frames will always be clearly
  250.    distinguishable from standard frames.
  251.  
  252.    Address-and-Control-Field-Compression
  253.  
  254.       Because the Address and Control field values are not constant, and
  255.       are modified as the frame is transported by the network switching
  256.       fabric, Address-and-Control-Field-Compression MUST NOT be
  257.       negotiated.
  258.  
  259.    Protocol-Field-Compression
  260.  
  261.       Note that unlike the HDLC framing, the Frame Relay framing does
  262.       not align the Information field on a 32-bit boundary.  Alignment
  263.       to a 32-bit boundary occurs when the NLPID is removed and Protocol
  264.       field is compressed to a single octet.  When this improves
  265.       throughput, Protocol-Field-Compression SHOULD be negotiated.
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275. Simpson                  expires in six months                  [Page 3]
  276. DRAFT                      PPP in Frame Relay               October 1993
  277.  
  278.  
  279. 4.  In-Band Protocol Demultiplexing
  280.  
  281.    The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish the
  282.    PPP encapsulation from the other NLPID encapsulations described in
  283.    [4].
  284.  
  285.    The joining of the PPP and NLPID number space has an added advantage,
  286.    in that the LCP Protocol-Reject can be used to indicate NLPIDs that
  287.    are not recognized.  This can eliminate "black-holes" that occur when
  288.    traffic is not supported.
  289.  
  290.    For those network-layer protocols which have no PPP Protocol
  291.    assignment, or which have not yet been implemented under the PPP
  292.    encapsulation, or which have not been successfully negotiated by a
  293.    PPP NCP, another method of encapsulation defined under [4] SHOULD be
  294.    used.
  295.  
  296.    Currently, there are no conflicts between NLPID and PPP Protocol
  297.    values.  If a future implementation is configured to send a NLPID
  298.    value which is the same as a compressed Protocol field, that Protocol
  299.    field MUST NOT be sent compressed.
  300.  
  301.    On reception, the first octet following the header is examined.  If
  302.    the octet is zero, it MUST be assumed that the packet is formatted
  303.    according to [4].
  304.  
  305.    PPP encapsulated packets always have a non-zero octet following the
  306.    header.  If the octet is not the PPP NLPID value (CF hex), and
  307.    Protocol-Field-Compression is enabled, and the associated NCP has
  308.    been negotiated, then it is expected to be a compressed PPP Protocol
  309.    value.  Otherwise, it MUST be assumed that the packet is formatted
  310.    according to [4].
  311.  
  312.    The Protocol field value 0x00cf is not allowed (reserved) to avoid
  313.    ambiguity when Protocol-Field-Compression is enabled.  The value MAY
  314.    be treated as a PPP Protocol that indicates that another PPP Protocol
  315.    packet follows.
  316.  
  317.    Initial LCP packets contain the sequence cf-c0-21 following the
  318.    header.  When a LCP Configure-Request packet is received and
  319.    recognized, the PPP link enters Link Establishment phase.
  320.  
  321.    The accidental connection of a link to feed a multipoint network (or
  322.    multicast group) SHOULD result in a misconfiguration indication.
  323.    This can be detected by multiple responses to the LCP Configure-
  324.    Request with the same Identifier, coming from different framing
  325.    addresses.  Some implementations might be physically unable to either
  326.    log or report such information.
  327.  
  328.  
  329.  
  330. Simpson                  expires in six months                  [Page 4]
  331. DRAFT                      PPP in Frame Relay               October 1993
  332.  
  333.  
  334.    Once PPP has entered the Link Establishment phase, data packets with
  335.    other NLPID values MUST NOT be sent, and on receipt such packets MUST
  336.    be silently discarded, until the PPP link enters the Network-Layer
  337.    Protocol phase.
  338.  
  339.    An implementation which requires PPP configuration (and other PPP
  340.    features such as authentication) MAY shut down the link when
  341.    configuration fails.  Otherwise, when the Configure-Request sender
  342.    reaches the Max-Configure limit, it MUST fall back to send only
  343.    frames encapsulated according to [4].
  344.  
  345.  
  346. 5.  Out-of-Band signaling
  347.  
  348.    There is no generally agreed method of out-of-band signalling.  Until
  349.    such a method is universally available, an implementation MUST use
  350.    In-Band Protocol Demultiplexing for both Permanent and Switched
  351.    Virtual Circuits.
  352.  
  353.  
  354. 6.  Configuration Details
  355.  
  356.    The following Configurations Options are recommended:
  357.  
  358.       Magic Number
  359.       Protocol Field Compression
  360.  
  361.    The standard LCP configuration defaults apply to Frame Relay links,
  362.    except MRU.
  363.  
  364.    To ensure interoperability with existing Frame Relay implementations,
  365.    the initial Maximum-Receive-Unit (MRU) is 1600 octets [4].  This only
  366.    affects the minimum required buffer space available for receiving
  367.    packets, not the size of packets sent.
  368.  
  369.    The typical network feeding the link is likely to have a MRU of
  370.    either 1500, or 2048 or greater.  To avoid fragmentation, the
  371.    Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
  372.    exceed 1500, unless a peer MRU of 2048 or greater is specifically
  373.    negotiated.
  374.  
  375.    Some Frame Relay switches are only capable of 262 octet frames.  It
  376.    is not recommended that anyone deploy or use a switch which is
  377.    capable of less than 1600 octet frames.  However, PPP implementations
  378.    MUST be configurable to limit the size of LCP packets which are sent
  379.    to 259 octets (which leaves room for the NLPID and Protocol fields),
  380.    until LCP negotiation is complete.
  381.  
  382.  
  383.  
  384.  
  385. Simpson                  expires in six months                  [Page 5]
  386. DRAFT                      PPP in Frame Relay               October 1993
  387.  
  388.  
  389.    XID negotiation is not required to be supported for links which are
  390.    capable of PPP negotiation.
  391.  
  392.    Inverse ARP is not required to be supported for PPP links.  That
  393.    function is provided by PPP NCP negotiation.
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440. Simpson                  expires in six months                  [Page 6]
  441. DRAFT                      PPP in Frame Relay               October 1993
  442.  
  443.  
  444. Security Considerations
  445.  
  446.    Security issues are not discussed in this memo.
  447.  
  448.  
  449. References
  450.  
  451.    [1]   Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in
  452.          progress.
  453.  
  454.    [2]   International Telegraph and Telephone Consultative Committee,
  455.          CCITT Recommendation Q.922, "ISDN Data Link Layer Specification
  456.          for Frame Mode Bearer Services", April 1991.
  457.  
  458.    [3]   Simpson, W. A., "PPP HDLC Framing", work in progress.
  459.  
  460.    [4]   Bradley,  T.,  Brown, C., and Malis, A., "Multiprotocol
  461.          Interconnect over Frame Relay", RFC 1294, January 1992.
  462.  
  463.    [5]   ISO/IEC TR 9577, "Information technology - Telecommunications
  464.          and Information exchange between systems - Protocol
  465.          Identification in the network layer", 1990 (E) 1990-10-15.
  466.  
  467.  
  468. Acknowledgments
  469.  
  470.    This design was inspired by the paper "Parameter Negotiation for the
  471.    Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
  472.    University of California, Berkeley, 1992, unpublished.
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495. Simpson                  expires in six months                  [Page 7]
  496. DRAFT                      PPP in Frame Relay               October 1993
  497.  
  498.  
  499. Chair's Address
  500.  
  501.    The working group can be contacted via the current chair:
  502.  
  503.       Fred Baker
  504.       Advanced Computer Communications
  505.       315 Bollay Drive
  506.       Santa Barbara, California  93117
  507.  
  508.       EMail: fbaker@acc.com
  509.  
  510.  
  511. Author's Address
  512.  
  513.    Questions about this memo can also be directed to:
  514.  
  515.       William Allen Simpson
  516.       Daydreamer
  517.       Computer Systems Consulting Services
  518.       1384 Fontaine
  519.       Madison Heights, Michigan  48071
  520.  
  521.       EMail: Bill.Simpson@um.cc.umich.edu
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550. Simpson                  expires in six months                  [Page 8]
  551. DRAFT                      PPP in Frame Relay               October 1993
  552.  
  553.  
  554.                            Table of Contents
  555.  
  556.  
  557.      1.     Introduction ..........................................    1
  558.  
  559.      2.     Physical Layer Requirements ...........................    2
  560.  
  561.      3.     The Data Link Layer ...................................    2
  562.         3.1       Frame Format ....................................    3
  563.         3.2       Modification of the Basic Frame .................    3
  564.  
  565.      4.     In-Band Protocol Demultiplexing .......................    4
  566.  
  567.      5.     Out-of-Band signaling .................................    5
  568.  
  569.      6.     Configuration Details .................................    5
  570.  
  571.      SECURITY CONSIDERATIONS ......................................    7
  572.  
  573.      REFERENCES ...................................................    7
  574.  
  575.      ACKNOWLEDGEMENTS .............................................    7
  576.  
  577.      CHAIR'S ADDRESS ..............................................    8
  578.  
  579.      AUTHOR'S ADDRESS .............................................    8
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607. Bill.Simpson@um.cc.umich.edu
  608.